IBIS Macromodel Task Group Meeting date: 8 July 2008 Members (asterisk for those attending): Ambrish Varma, Cadence Design Systems Anders Ekholm, Ericsson * Arpad Muranyi, Mentor Graphics Corp. Barry Katz, SiSoft * Bob Ross, Teraspeed Consulting Group Brad Brim, Sigrity Brad Griffin, Cadence Design Systems David Banas, Xilinx Donald Telian, consultant Doug White, Cisco Systems Essaid Bensoudane, ST Microelectronics Fangyi Rao, ??? Ganesh Narayanaswamy, ST Micro Gang Kang, Sigrity Hemant Shah, Cadence Design Systems Ian Dodd, Agilent Joe Abler, IBM * John Angulo, Mentor Graphics John Shields, Mentor Graphics Ken Willis, Cadence Design Systems Kumar Lance Wang, Cadence Design Systems Luis Boluna, Cisco Systems * Michael Mirmak, Intel Corp. Mike LaBonte, Cisco Systems Mike Steinberger, SiSoft * Mustansir Fanaswalla, Xilinx Patrick O'Halloran, Tiburon Design Automation Paul Fernando, NCSU Radek Biernacki, Agilent (EESof) * Randy Wolff, Micron Technology Ray Comeau, Cadence Design Systems Richard Mellitz, Intel Richard Ward, Texas Instruments * Sam Chitwood, Sigrity Sanjeev Gupta, Agilent Shangli Wu, Cadence Design Systems Sid Singh, Extreme Networks Stephen Scearce, Cisco Systems Steve Pytel, Ansoft Syed Huq, Cisco Systems Syed Sadeghi, ST Micro * Terry Jernberg, Cadence Design Systems * Todd Westerhoff, SiSoft Vikas Gupta, Xilinx Vuk Borich, Agilent * Walter Katz, SiSoft Zhen Mu, Cadence Design Systems ----- Opens: - Randy Wolff agreed to take minutes in Mike LaBonte's absence. - Bob Ross asked to make a statement before the main discussion started. -------------------------- Call for patent disclosure: - No one declared a patent. ------------- Review of ARs: - Walter: Update example with "Views" - done - Bob: Give us a Spice netlist example of your choice - Bob responded by email with a partial response. He does not plan to fully replicate what Walter has shown. Considers this task complete. - David Banas report Xilinx position on LTI assumption for SerDes - No update - Arpad: Write parameter passing syntax proposal (BIRD draft) for *-AMS models in IBIS that is consistent with the parameter passing syntax of the AMI models - TBD - TBD: Propose a parameter passing syntax for the SPICE - [External ...] also? - TBD - Arpad: Review the documentation (annotation) in the macro libraries. - Deferred until a demand arises or we have nothing else to do ------------- New Discussion: Continue discussion on the standard netlisting and modeling format - what should be the language of the standard netlist language? - what should be the language of the standard modeling language? - what "elements" should be included in the standard modeling language? - how are we going to solicit "buy-in" from EDA vendors to support the new elements of the standard? - Bob began opening remarks. - Has had private discussions with Walter and Scott McMorrow. - Must ask fundamental question of Should we continue with EMD? - We don't have a common vision of the whole project. - For the language, the scope of views is undefined. - Agenda items are very specific assuming we have a common vision, but we should answer the question first of resources, time schedule, and if this project fits in with IBIS. - Fully supports the EMD concept, but doesn't think it will work as presented. Thinks it should be limited to hooking up nodes for interconnect and maybe labeling some power/ground nodes. - Arpad: What if we started from scratch completely and answer the question of what the industry needs. What is the benefit to having a universal netlisting language? - Bob: Just write a reference document for an interconnect language bringing in any modules we want. - Thinks it is too big of a problem to write a translator. - Gave example: Top level is input/output. Module 1 has only one view. Module 2 has multiple views. Modules contain only comments. - This is a document, not a standard. - Michael M: In order to support customers, must demonstrate that products work. - For instance giving out topologies. Some customers demand full netlists for specific vendor tools. Would be very useful if we could hand out a complete system netlist that could be run in whatever tool the customer is using. - Walter: presented a document. - Went through Berkeley Spice manual and found all the elements we commonly use in interconnect netlists. - Showed 4 options for the format of EMD interconnect models. - Concluded that defining a specific language would be too difficult, so proposed a "Free Form" option. - "Free Form" specifies the name of the file and subcircuit and the "Sub-language" that the subcircuit is written in. The Sub-language must be documented with the "Spice" elements it uses. - He showed a simple netlist for a cable that included multiple views. - Bob: Walter's example follows what he wanted to see. - Arpad: this is basically a netlist to hook together top level subcircuits. - How would this guarantee compatibility between simulators? - Walter: It wouldn't. - Michael M: Doesn't think the proposal is useful unless it provides a common netlist language. - Bob: doesn't think it is a goal that the contents be interchangeable. - Arpad: What does each view represent in Walter's example? - Walter: Each view contains the entire circuit, but one view may have a fully coupled model and one may be an uncoupled model. - Walter: What are we trying to solve? We started with trying to describe packages. - Bob: We can do it all with another solution. - Michael M: We are answering Arpad's question. Netlists aren't the issues. We need a way to describe a package with elements that are spice-like. - Arpad: Why do we need a netlisting standard? These capabilities exist in many formats like Spice and AMS. The only thing we don't have is a pin list and AMS has this. - Walter: I don't understand what this all means. - Michael M: There is a difference between describing how every component connects together and describing its electrical behavior. Spice is good at doing both. We need a system level netlist connecting A to B to C without getting into the discussion of what is in the lower level. - Walter: If I have a package I can describe everything with one S-parameter file. I only care about the node connections. - Michael M: Spice does both things. I want to exchange top level information - How each one of the components is internally described is a separate discussion. - Todd: We won't get consensus on what is inside the block. The value of IBIS is in describing what various pins do. - Walter: Every subcircuit only hooks up pins that are available externally. - John: The key contribution of the proposal is the alternative views. - Bob: Contribution is common pin interface to views in multiple languages. - Michael M: Concerned with the need for virtual pins that are not physical pins, for measurement of differential signals for instance. - Arpad: Concerned with hooking together an entire system and having views of one part of the system in spice and views of another part in VHDL. How is this supported? - Walter: Model creators must be encouraged to support subsets of languages that will be supported by multiple EDA vendors. - Michael M: What is the topic of discussion next week? - Bob: We need to continue this general discussion. - Bob: To answer Arpad's original questions: Modeling language: all options are open Interconnect language: not defined yet What elements should be included: we don't define any elements - Arpad: What are the open questions for next week? - Walter: What functionality do we need in this solution at the top level? Do we need to write this spec? If yes, work through the details. - Arpad: Who is the best person to answer these questions? Isn't the question more appropriate for the model makers - is this useful? - Walter: We need buy-in from everybody. AR: Walter will propose a question for Arpad to distribute to the reflector to start discussion before the next meeting. Next meeting: 15 July 2008 12:00pm PT -----------